I can't give any better estimate when the 1000 Hz update will be released. Eric is currently working on significant updates for Kyoto and I am trying to finish an intermediate semi-compatible release of the public version with improved mods support.
After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.
---
About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).
Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.
I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.
By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.
---
About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).
Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.
I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.
By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
First thing I'd like to say is that, I agree, it would be great if LFS would store locally obvious things like PB and splits for any vehicle and track combination, and these recordings of your best lap so it can show live delta, and these other live statistics for racing (relative to other drivers, in better detail than the existing native system).
Second thing I have to say is that I can see quite a lot of complication with it and the various options these systems would need. At the moment I'm trying to finish an incompatible version, to then get the new tyre physics into a releasable state so we can finally release the new version. So I really can't take it on in the near future.
I'm wondering if any other programmers could do these, and if anything needs to be added to InSim to enable it. I know we have programmers with the skills to do it and probably the interest too, but programming is time consuming and programmers may be busy on other projects and work, so aren't ready to take up such a task. But in case anyone does want to at some time, before I can support it natively, I wonder what needs to be added to InSim. I know that LFS Lazy uses a combination of InSim and direct memory access but it would be very good if the direct access could be avoided. So if any programmers know what's currently missing from InSim and could enable such excellent features as seen in LFS Lazy, please let me know.
Second thing I have to say is that I can see quite a lot of complication with it and the various options these systems would need. At the moment I'm trying to finish an incompatible version, to then get the new tyre physics into a releasable state so we can finally release the new version. So I really can't take it on in the near future.
I'm wondering if any other programmers could do these, and if anything needs to be added to InSim to enable it. I know we have programmers with the skills to do it and probably the interest too, but programming is time consuming and programmers may be busy on other projects and work, so aren't ready to take up such a task. But in case anyone does want to at some time, before I can support it natively, I wonder what needs to be added to InSim. I know that LFS Lazy uses a combination of InSim and direct memory access but it would be very good if the direct access could be avoided. So if any programmers know what's currently missing from InSim and could enable such excellent features as seen in LFS Lazy, please let me know.
Thanks for the reports.
For three issues, I've released a minor update, Test Patch D35.
FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen
Misc option "Full physics for remote cars" is now enabled by default
FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
For three issues, I've released a minor update, Test Patch D35.
FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen
Misc option "Full physics for remote cars" is now enabled by default
FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
Minor update D35:
Misc option "Full physics for remote cars" is now enabled by default
FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen
https://www.lfs.net/forum/thread/102117
Misc option "Full physics for remote cars" is now enabled by default
FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen
https://www.lfs.net/forum/thread/102117
Thanks.
This problem can be eliminated by the "Avoid simple physics" option (that also prevents remote cars with high anti-roll settings jumping on the start grid).
The equivalent of "Avoid simple physics" is always set for karts. I'm wondering if it should simply be enabled for all vehicles now. There is a certain CPU cost that can be observed by pressing the F button in the CPU usage display (available at top right of Misc options).
The trouble with your mod (without looking into it in detail) is the wheels are small and light. The "simple physics" doesn't operate at a high enough frequency to remain stable, although it is handled fine by the normal physics.
This problem can be eliminated by the "Avoid simple physics" option (that also prevents remote cars with high anti-roll settings jumping on the start grid).
The equivalent of "Avoid simple physics" is always set for karts. I'm wondering if it should simply be enabled for all vehicles now. There is a certain CPU cost that can be observed by pressing the F button in the CPU usage display (available at top right of Misc options).
The trouble with your mod (without looking into it in detail) is the wheels are small and light. The "simple physics" doesn't operate at a high enough frequency to remain stable, although it is handled fine by the normal physics.
Rim editor updates coming soon
Hello mod developers.
As many of you know, I am trying to get to a full version release so that all racers get the benefit of the recent updates, which I won't list here (you can read the first post of the editor test patch thread).
I noticed that some people, who want better looking wheels, have been using workarounds for deficiencies in the wheel rim system. So I really had to sort that out, even if it delays this full version release and my subsequent work on tyre physics. Sorry to the physics purists but I can't really leave the editor with such glaring issues. Wheel designs are very important and some people are putting a lot of effort into their mods. It's not good to have more and more mods with workarounds for a system that needs changing. So I have worked for a few weeks on this system for rim and wheel graphics.
Here I will list the updates and then post a few pictures:
The new lighting system affects both the rim and spoke objects. The lighting at each vertex depends on its depth in the wheel and the direction it faces, by an approximation system that is also affected by the "concealed wheels" setting (that makes it darker on the inside).
I think this ambient lighting should also be applied to any 'brake' or 'hub' objects that are found, because they are also within the wheel cylinder. But let me know if there are other uses for such objects, that mean the new lighting shouldn't be applied to them.
More notes:
I would advise mod makers not to use rim workarounds for now, as the auto repair is likely to affect the look of your work in the rim flange area. It's probably best to go along with the default LFS rims at the moment. If you do use workarounds, please be ready to fix your mods as soon as the update is released.
The update will be incompatible. Not for physical reasons, but simply because the file format is updated. That means, old LFS will no longer be able to load mods saved with the new version. There will be a test patch that can load the newly saved mods, of course. I will start a few test servers for people to test their mods, during the short period of time when the incompatible test patch is out and we are in final testing before the official update. I hope that period will be only around two weeks, to allow enough time for testing.
As many of you know, I am trying to get to a full version release so that all racers get the benefit of the recent updates, which I won't list here (you can read the first post of the editor test patch thread).
I noticed that some people, who want better looking wheels, have been using workarounds for deficiencies in the wheel rim system. So I really had to sort that out, even if it delays this full version release and my subsequent work on tyre physics. Sorry to the physics purists but I can't really leave the editor with such glaring issues. Wheel designs are very important and some people are putting a lot of effort into their mods. It's not good to have more and more mods with workarounds for a system that needs changing. So I have worked for a few weeks on this system for rim and wheel graphics.
Here I will list the updates and then post a few pictures:
Wheel rims:
Rim can now be fully edited, there are no fixed surfaces
Rim no longer blends seamlessly into the wheels without an edge
Allows more design flexibility for alloy wheels and steel wheels
Removed: edge extra width / lip depth / inner depth / black inner
A simple alloy style edge is automatically added to existing rims
Option to allow separate wheel style (rim/spokes) for front & rear
Tyre vs rim guide in the vehicle editor helps set correct rim size
Rim has 60 segments around instead of 30 (tyres still 30 around)
Rim guide in rim editor shows regions that should be covered
The colour at the bottom of the list can now be deleted
3D view visible in rim editor can now be rotated
Wheel lighting:
New ambient lighting system for wheels and spokes
Separate options for front and rear "concealed wheels" lighting
The new lighting system replaces the old 'rim shade' option
Auto repair removes the Dx/Ex darker colours from rim
The new lighting system affects both the rim and spoke objects. The lighting at each vertex depends on its depth in the wheel and the direction it faces, by an approximation system that is also affected by the "concealed wheels" setting (that makes it darker on the inside).
I think this ambient lighting should also be applied to any 'brake' or 'hub' objects that are found, because they are also within the wheel cylinder. But let me know if there are other uses for such objects, that mean the new lighting shouldn't be applied to them.
More notes:
I would advise mod makers not to use rim workarounds for now, as the auto repair is likely to affect the look of your work in the rim flange area. It's probably best to go along with the default LFS rims at the moment. If you do use workarounds, please be ready to fix your mods as soon as the update is released.
The update will be incompatible. Not for physical reasons, but simply because the file format is updated. That means, old LFS will no longer be able to load mods saved with the new version. There will be a test patch that can load the newly saved mods, of course. I will start a few test servers for people to test their mods, during the short period of time when the incompatible test patch is out and we are in final testing before the official update. I hope that period will be only around two weeks, to allow enough time for testing.
I'll start by linking to a couple of threads which show a lot of the work I have been doing recently:
Test Patch D33: https://www.lfs.net/forum/thread/102117
Editor Test Patch D40: https://www.lfs.net/forum/thread/102626
As you can see, particularly on the Editor Test Patch thread, I have made a huge number of improvements for the mod support. I find it a great thing that LFS is a way for people to be creative, and the mods system is a massive new part of that. It was very "new" indeed when released (basically a bunch of dev editors brushed up a bit) which is why there have been so many issues to sort out.
In the past months, while I have been doing these, Eric was at first finishing South City, which took a lot longer than he anticipated. Filling those holes is not easy, and he likes to fill them just as people would actually "fill the holes" when building a real city. I received an update recently and tested it, reported a bunch of issues and he fixed those. We find the completion level very good now, basically good enough for public testing when we can get the full version together. He is now working on the Kyoto improvements. As you may know from the official progress reports, that was never finished before Eric moved onto the South City, that turned into an epic development and massive expansion.
On my side, I'm trying to finish test patch things so that I can finally complete the tyre physics. In fact my current focus is on wheels, both in the development and public version. In the public version there should be a graphical update for wheels in the next few days, to go along with the many updates there have been for mods. Again, please read the test patch threads to know what I'm talking about.
There is also other work I do, that you never see, such as updates for the track editor. Suppose Eric is doing a task and finds he has to do something in a laborious or repetitive way and one of us thinks of a new editor function that could help him achieve certain tasks more quickly, then I always want to stop whatever else I was doing and work on the track editor for a few days.
I'm trying to get to an official release so my focus can then be entirely on the tyre physics in the development version. It has taken me much longer than expected to complete this round of test patches as there were so many unfinished things in the mods system. When I see creators, working hard and having to use workarounds for issues, I feel a great responsibility to get that issue sorted out.
Of course, the priorities I attach to various tasks, will not be the same as someone else's priority. We all have different priorities, so there's not a person in the world who could agree with all my choice of tasks to work on. But I must work on what I feel is important. Actually I find it a huge mental effort to complete these tasks, and that's why I need to follow the inspiration. Sometimes I'm awake at night working out how to do something, then experimenting and testing, it's a lot of work.
It takes a long time, but there is always progress.
I understand there is a conflict at the boundary between LFS generated tyre/rim and the user created objects. It's something I need to consider. I can't jump to quick fixes. This is because the tyre generation and profile will change a bit in future and existing mods cannot be broken at that point. Maybe LFS needs some defined profile styles for physically plausible rims, including a proper 3D edge between the rim and the tyre, and/or some way to interface cleanly with user defined rims. The current tyre shape is a compromise, designed a long time ago, so I need to examine how the visual tyre and rim width are produced from the "Rim width" setting in the vehicle editor. I realise there is a resolution issue - some mod creators want to use a lot of triangles around the edge to create a perfectly round appearance, but that is not compatible with the tyre resolution as the LFS tyres can move and they are CPU-expensive to send to the graphics card each frame, even in the new LFS system. No doubt there is a better way to do that too, with a special shader.
I do see the issues as I can see the high quality rims that people want to make, so I have to think about this a while. At this point I think the changes are not in the immediate future, as you know I'm trying to do this full release to get back to the tyre physics, so things will be easier when I only have to work on one version of LFS, and we all get the benefit of the new graphics.
Anyway, for today there is a new update, D40.
Vehicle editor:
Hub object custom colours now appear in the list of wheel colours
Modeller:
Reflect object function is now available for individual subobjects
Combined clean object buttons into a single button with a dialog
Spoke mode "export SRE" saves combined spokes as a modeller object
Spoke mode "import SRE" function to load modeller object as a spoke
Download: https://www.lfs.net/forum/thread/102626
I do see the issues as I can see the high quality rims that people want to make, so I have to think about this a while. At this point I think the changes are not in the immediate future, as you know I'm trying to do this full release to get back to the tyre physics, so things will be easier when I only have to work on one version of LFS, and we all get the benefit of the new graphics.
Anyway, for today there is a new update, D40.
Vehicle editor:
Hub object custom colours now appear in the list of wheel colours
Modeller:
Reflect object function is now available for individual subobjects
Combined clean object buttons into a single button with a dialog
Spoke mode "export SRE" saves combined spokes as a modeller object
Spoke mode "import SRE" function to load modeller object as a spoke
Download: https://www.lfs.net/forum/thread/102626
I agree, I'm having a look at this to see what sort of results I can come up with, to make the public LFS dashboards have a similar brightness to the ones in the editor, without making older ones excessively bright. I think it's a few hours to carefully figure this out, maybe can release an update tomorrow with better brightness in game.
I'm not really looking forward to that, no!
I don't have plans to update those clocks at this time. I felt the dial clocks were in serious need of an update for all those reasons. People were forced into either accepting a look they didn't want, or doing workarounds that would not be the proper way to do it. I didn't even plan to do this but sort of fell into it because of the need to add the damage light to the clocks. I don't regret it though, as I'm happy to see what results people can come up with. But it has been surprisingly intense work for the whole of last week and already two days this week.
All I really want to do is get this official update finished so I can leave it and work on the tyre physics. I want to get to the situation where everyone has the new graphics and I can work on one version of LFS instead of copying all the updates into two divergent versions of LFS.
Thanks for the test / demonstration. 
One tip for people making custom dashboards:
To protect your mod from future physics changes, in the Speedo settings you should set "Max" to manual. Even if the auto value is OK right now, it's possible that future physics changes will result in a different estimated maximum speed, which could mess up your speedo accuracy.
I think it's less of an issue with the tacho as in that case auto is based on engine setting "Redline" so should not change unexpectedly. Using the manual setting could still help by allowing to you adjust the redline without changing the tacho range.
One tip for people making custom dashboards:
To protect your mod from future physics changes, in the Speedo settings you should set "Max" to manual. Even if the auto value is OK right now, it's possible that future physics changes will result in a different estimated maximum speed, which could mess up your speedo accuracy.
I think it's less of an issue with the tacho as in that case auto is based on engine setting "Redline" so should not change unexpectedly. Using the manual setting could still help by allowing to you adjust the redline without changing the tacho range.
It's extremely unlikely to be related to the update.
All such times there have been sound and frame rate issues, it has been due to mods with bad sound settings or other issues causing extremes of physics, packet hacks, etc.
We have had cases where such issues were deliberate sabotage, others where it was an innocent mistake, and others due to the low resolution physics not being able to deal with a mod. In no case has it been caused by an LFS update. On the contrary, LFS updates have been released to prevent such issues.
I really have no idea how your exe could be corrupted.
Maybe the issue is reproducible in an MPR. If you could provide an MPR of the server at the trime of the issue, and explain which driver's viewpoint to take, and which time point in the replay, in order to experience the issue, then it should be possible for me to track down the problem. Maybe a good idea to state which server it was on (I guess just a ride?) and what time it was? I guess someone must have an MPR that includes the event?
All such times there have been sound and frame rate issues, it has been due to mods with bad sound settings or other issues causing extremes of physics, packet hacks, etc.
We have had cases where such issues were deliberate sabotage, others where it was an innocent mistake, and others due to the low resolution physics not being able to deal with a mod. In no case has it been caused by an LFS update. On the contrary, LFS updates have been released to prevent such issues.
I really have no idea how your exe could be corrupted.
Maybe the issue is reproducible in an MPR. If you could provide an MPR of the server at the trime of the issue, and explain which driver's viewpoint to take, and which time point in the replay, in order to experience the issue, then it should be possible for me to track down the problem. Maybe a good idea to state which server it was on (I guess just a ride?) and what time it was? I guess someone must have an MPR that includes the event?
Last edited by Scawen, .
As you may know, I'm trying to finish this round of test patches and release an official version so I can focus fully on tyre physics.
Unfortunately, finishing always takes longer than expected but I'm getting there. One thing to add was the dashboard version of the engine damage light. I did that on Monday, but noticed certain issues with dashboards while I was in the dashboard editor. Remembering various issues and requests for improvement, on Tuesday I started to add options for the tacho (allowing x100, steps of 5, set maximum value) and on Wednesday for the speedo (set maximum value, make mph and km/h have the same needle position). On Thursday I added several options that can be applied to all the dials. Finally today I've added the option to show and position the unit (km/h or mph on speedo, x100 or x1000 on the tacho).
I'm sure many of you will find these options useful and they will add some variety and realism to the traditional style dashboards you set up. I don't suggest that this is complete or allows all the possibilities you would like, but these are the things I could do quickly, in a semi-compatible version.
To see the effect of these options in game, you will need Test Patch D26.
By "semi-compatible" I mean that versions before D26 can still load vehicles you save with this new version, but they won't see the effect of the new options.
Vehicle editor:
Engine damage light can be enabled (in Transmission tab)
Maximum value for main body drag increased from 1.0 to 6.0
Some tooltips added and descriptions adjusted in Aerodynamics tab
Estimated max speed (in Aerodynamics) shows speed in mph or km/h
FIX: Dashboard for electric vehicles was switched off in editor
Dashboard editor:
Speedo:
- set maximum value in km/h (steps of 5)
- option to show units (km/h or mph)
Tacho:
- set maximum value
- x100 or x1000
- gap 1/2 (x1000) or 5/10 (x100)
- options to show units (x100 or x1000)
Options on all gauges:
- needle colour = text colour
- needle is long
- needle above pivot
- hide pivot
- hide numbers
- hide symbol (if applicable)
- hide marks
- smaller text
Download: https://www.lfs.net/forum/thread/102626-Editor-Test-Patch-0-7D34
Unfortunately, finishing always takes longer than expected but I'm getting there. One thing to add was the dashboard version of the engine damage light. I did that on Monday, but noticed certain issues with dashboards while I was in the dashboard editor. Remembering various issues and requests for improvement, on Tuesday I started to add options for the tacho (allowing x100, steps of 5, set maximum value) and on Wednesday for the speedo (set maximum value, make mph and km/h have the same needle position). On Thursday I added several options that can be applied to all the dials. Finally today I've added the option to show and position the unit (km/h or mph on speedo, x100 or x1000 on the tacho).
I'm sure many of you will find these options useful and they will add some variety and realism to the traditional style dashboards you set up. I don't suggest that this is complete or allows all the possibilities you would like, but these are the things I could do quickly, in a semi-compatible version.
To see the effect of these options in game, you will need Test Patch D26.
By "semi-compatible" I mean that versions before D26 can still load vehicles you save with this new version, but they won't see the effect of the new options.
Vehicle editor:
Engine damage light can be enabled (in Transmission tab)
Maximum value for main body drag increased from 1.0 to 6.0
Some tooltips added and descriptions adjusted in Aerodynamics tab
Estimated max speed (in Aerodynamics) shows speed in mph or km/h
FIX: Dashboard for electric vehicles was switched off in editor
Dashboard editor:
Speedo:
- set maximum value in km/h (steps of 5)
- option to show units (km/h or mph)
Tacho:
- set maximum value
- x100 or x1000
- gap 1/2 (x1000) or 5/10 (x100)
- options to show units (x100 or x1000)
Options on all gauges:
- needle colour = text colour
- needle is long
- needle above pivot
- hide pivot
- hide numbers
- hide symbol (if applicable)
- hide marks
- smaller text
Download: https://www.lfs.net/forum/thread/102626-Editor-Test-Patch-0-7D34
There are no changes to physics. Maybe on the server you were on, someone applied a handicap. But more likely a psychological, physiological or environmental effect. Our perception and skills vary from one day to the next.
Thanks for the report. This is fixed in D29 which I'll upload in a minute.
Thank you and don't worry, that is not insulting.
I don't pretend to know everything. I should have a look at a crash handler, though I don't want to spend much time on it now, a good one could save time in the future.
At least to write out exception code, crash address and the module might be nice so people don't have to look in Windows logs. A call stack would be great information too and could solve more cases, especially if the crash is in a commonly used function or in a non-LFS module (called by some function in LFS).
I seem to remember looking at this a bit in the past and it was apparently not easy to obtain a call stack for some reason, or maybe it required a lot of knowledge. Well, I guess that's why you made your own library for it. Anyway, I will read up a little can contact you for more information if I want to do something. Though my priority is to quickly release the new version and get back to the tyre physics.
Interesting thought but it won't be in this round of test patches. Everything I do in the current public version must be merged into the separate development version, which isn't always easy. Also any changes in the core of the physics system are likely to invalidate all the hotlaps, which isn't worth doing at the moment. Also, incompatible setups, online compatibility, interface updates, etc...
I look forward to releasing the development version, so we only have one version and it will be much easier to add new features then.
I just watched this 12 min video about heave springs.
https://www.youtube.com/watch?v=lNInCfCkrkE
I look forward to releasing the development version, so we only have one version and it will be much easier to add new features then.
I just watched this 12 min video about heave springs.
https://www.youtube.com/watch?v=lNInCfCkrkE
Last edited by Scawen, .
The LFS developers should host instructions on how to reverse engineer someone's software without their permission?
Honestly, I'm not even sure programs should be allowed to work the way LFS Lazy does, hacking into LFS. But it was allowed in this case, so that is beside the point.
I've added a couple of the most requested features from LFS Lazy into a recent test patch.
I know there are many other features of Lazy that are still wanted, though I assume you would prefer me to to continue working on the new tyre physics, instead of trying to implement the features of LFS Lazy?
It's possible to recreate many of the features of LFS Lazy without resorting to hacking obsolete software which is itself a hack, even if a very good one. I mentioned above, the PACT Driving Assistant which is currently in development has many features that may be of interest (although I don't know which features of LFS Lazy can or cannot be done by PACT).
Honestly, I'm not even sure programs should be allowed to work the way LFS Lazy does, hacking into LFS. But it was allowed in this case, so that is beside the point.
I've added a couple of the most requested features from LFS Lazy into a recent test patch.
I know there are many other features of Lazy that are still wanted, though I assume you would prefer me to to continue working on the new tyre physics, instead of trying to implement the features of LFS Lazy?
It's possible to recreate many of the features of LFS Lazy without resorting to hacking obsolete software which is itself a hack, even if a very good one. I mentioned above, the PACT Driving Assistant which is currently in development has many features that may be of interest (although I don't know which features of LFS Lazy can or cannot be done by PACT).
Last edited by Scawen, .
I'm working on it. Progress is not stalled.
I did spend a lot of time last month on test patch and editor updates, but that's not my focus now. I won't go into all the reasons why that happened, but there was an important update, then I saw the E-Challenge, saw something that could be improved there, thought of a few other useful improvements, one thing lead to another...
Not a problem, that's all good. The updates were significant and important.
The idea of the progress reports wasn't really "this is what I will do forever". It was an insight into the development process, and I went into extreme detail, maybe even too personal, so people could really understand what being a programmer is about.
Tyre physics doesn't go the way multithreading goes. For me, it's not really suitable for rapid progress reports. There's a lot of experimentation and testing, research and hard thinking.
However much you want the new version released, multiply that by 100 (rough estimate) and that's how much I want it released. The new version is what I work on and think about for many hours every day. All I can really say at this point is don't worry, I'm on it.
I did spend a lot of time last month on test patch and editor updates, but that's not my focus now. I won't go into all the reasons why that happened, but there was an important update, then I saw the E-Challenge, saw something that could be improved there, thought of a few other useful improvements, one thing lead to another...
Not a problem, that's all good. The updates were significant and important.
The idea of the progress reports wasn't really "this is what I will do forever". It was an insight into the development process, and I went into extreme detail, maybe even too personal, so people could really understand what being a programmer is about.
Tyre physics doesn't go the way multithreading goes. For me, it's not really suitable for rapid progress reports. There's a lot of experimentation and testing, research and hard thinking.
However much you want the new version released, multiply that by 100 (rough estimate) and that's how much I want it released. The new version is what I work on and think about for many hours every day. All I can really say at this point is don't worry, I'm on it.
This is really not on topic and has nothing to do with the test patch.
I'm trying to finish the things in the test patch and get back to tyre physics. The test patch thread will not become a random suggestions thread.
Remember the forum section for suggestions: https://www.lfs.net/forum/8-Improvement-Suggestions
Last edited by Scawen, .
Maybe a clutch pedal bar replacement at first, quick and easy to implement (hopefully, if the values can be extracted from the physics system without any trouble). And eventually something for the dashboard display.
I know a lot of people would like to hear more progress.
I've been working on tyre physics but I'm not ready to do a proper report yet.
Just to say for now that a tyre model may be broken into:
- carcass model
- tread model
- friction model
The carcass model is about how the tyre's structure and pressure affect the output forces depending on the state of the wheel. I can use my simulated tyre carcass (non-realtime) to see how some of these forces vary. I've been making changes to the in-game realtime model to more closely match the simulated tyre.
I don't claim that the simulated tyre is an extremely accurate model of a real tyre but it does give an insight into distortion and deflection and how that changes with tyre proportions and pressure.
I'm experimenting, adjusting and thinking a lot so will report some results eventually!
I've been working on tyre physics but I'm not ready to do a proper report yet.
Just to say for now that a tyre model may be broken into:
- carcass model
- tread model
- friction model
The carcass model is about how the tyre's structure and pressure affect the output forces depending on the state of the wheel. I can use my simulated tyre carcass (non-realtime) to see how some of these forces vary. I've been making changes to the in-game realtime model to more closely match the simulated tyre.
I don't claim that the simulated tyre is an extremely accurate model of a real tyre but it does give an insight into distortion and deflection and how that changes with tyre proportions and pressure.
I'm experimenting, adjusting and thinking a lot so will report some results eventually!
As mentioned in another post, I've had an initial look and made some notes about converting LFS to 64-bit. I don't see any real problems but a lot of lines need to change. Initial thoughts are it might take a week or two, which puts it on a low priority compared with tyre physics. I can't really think of any short-term benefits at the moment other than allegedly it's the only way to connect to OpenXR (which I've barely heard of and obviously would have to code for as well).
Anyway, maybe you could tell me what is the difference or connections between OpenXR and OpenVR and SteamVR?
I thought that the aim of OpenVR was exactly what you seem to be suggesting is the aim of OpenXR. But as far as I know, the only implementation of OpenVR was SteamVR? But thought that didn't have to be the case?
I must say that OpenVR/SteamVR has been really fantastic in providing a way for many games to connect with many headsets. Has its time really come, and why?
I could go reading and researching but thought you might give me a short explanation (if you feel like it).
Anyway, maybe you could tell me what is the difference or connections between OpenXR and OpenVR and SteamVR?
I thought that the aim of OpenVR was exactly what you seem to be suggesting is the aim of OpenXR. But as far as I know, the only implementation of OpenVR was SteamVR? But thought that didn't have to be the case?
I must say that OpenVR/SteamVR has been really fantastic in providing a way for many games to connect with many headsets. Has its time really come, and why?
I could go reading and researching but thought you might give me a short explanation (if you feel like it).
There are some shadow options. Quad core is fine for new LFS as it has two main threads (graphics and physics). That leaves 2 cores for OS use and other minor threads. I think 2.56 GHz should be OK for most things. I've been developing on a dual core CPU with 3.2 GHz (nice fast computer, despite what people seem to think). I imagine you might want to turn down some settings at heavy tracks. But I can't say anything for sure. That might struggle with a full field of visible cars at South City, for example. But my words are pure speculation. We aren't like a big game studio that has actual budgets for such things, it's more like have a go and see what happens, try to optimise what uses a lot of resources.
EDIT: As for shadow options, the biggest one is to switch off shadows in mirrors. But that means very illuminated mirror views if you drive in a dark place. I have on my list to have an option for the number of shadow cascades to be drawn in mirror, Maybe it will not be noticeable to skip the cascade responsible for the distant shadows, for the mirror view.
Also you can set 1024/1536/2048 for the texture resolution per cascade (number of cascades normally 4).
It could be possible to do more optimisations like options to remove smaller objects from the distant cascades. So you still get building shadows but small objects don't produce a shadow which you probably can't see anyway. The trouble with shadow maps is they can draw a lot of things that you can't see and make no difference to anything, but it's hard to stop them doing that in a good way.
I think it always uses the same LOD for the shadow, as for the main object.
But LOD2 is still used to create the soft ambient shadow below the car, even if main object is LOD1.
Last edited by Scawen, .
No, it is generated locally. I think the clue is that it is a translated message? Unless it's actually generated by your InSim program? I've looked in the code and can't see anything that would remove a dot from a user name, so was hoping for an easier reproduction.
I'm trying to do things in a simple way, rather than spending a long time creating fake user names, to try to reproduce the fault. This is to save me time as I have a lot of other things to work on. Maybe you could get your friend with a user name that starts with a dot to join a server to create a short MPR.
When i searched our system, I couldn't find a user called ".user1" so assumed it was an example and you are protecting the identity of the user?
A similar thing has happened on the test patch forum. A bug has been reported, I asked for a reproduction, but no-one is interested. That's fine but it'll take me longer to develop the tyre physics if I'm the only one reproducing obscure bugs.
I'm trying to do things in a simple way, rather than spending a long time creating fake user names, to try to reproduce the fault. This is to save me time as I have a lot of other things to work on. Maybe you could get your friend with a user name that starts with a dot to join a server to create a short MPR.
When i searched our system, I couldn't find a user called ".user1" so assumed it was an example and you are protecting the identity of the user?
A similar thing has happened on the test patch forum. A bug has been reported, I asked for a reproduction, but no-one is interested. That's fine but it'll take me longer to develop the tyre physics if I'm the only one reproducing obscure bugs.
Were all the conditions definitely met? In pit stop, etc. I could stop and test this using two user accounts but I'm in the middle of tyre physics so don't really want to stop at the moment, so if anyone else can test that would be appreciated. I'd suggest testing with D9 and D versions together. If all works then I'd suggest that all is OK.
Last edited by Scawen, .
Reason : edit: originally wrote D8, meant to say D9
LFS mechanics are among the world's finest.
Thank you, now fixed in D8.
It should be a lot better now when tabbing to other cars, often a car would seem to skate off sideways a bit (or a lot) when it hadn't been on the screen for a short while. Partly because it was in low-res physics before you brought it onto screen.
So I hope it might improve the appearance of LFS during the broadcasts quite a bit, along with the D4 update "Reduced glitch of multiplayer cars after TAB or fast forward replay".
FGED GREDG RDFGDR GSFDG